feat: use MCP SDK for recipient resolution - #13

internal/teamsctl/mcp.go:103

• With limit now optional, calling FindConversations(..., input.Limit) will pass 0 when the field is omitted, returning all conversations by default. If the input is changed to *int, apply a default (e.g. 50) when nil so agents don't accidentally enumerate everything.

	conversations, err := service.FindConversations(input.Query, input.Kind, input.Limit)
	return nil, conversations, err

internal/teamsctl/mcp.go:32

• Same as list_conversations: using int for limit makes the default "0" (all messages) when the field is omitted, which can unintentionally fetch an unbounded history. Use *int so you can keep a safe default (e.g. 50) while still allowing 0 explicitly.

type messagesInput struct {
	Recipient      string `json:"recipient,omitempty" jsonschema:"Recipient phrase from the user, such as Mike, Mike and Charlie, ASM group chat, or ASM channel."`
	ConversationID string `json:"conversation_id,omitempty" jsonschema:"Deprecated: use recipient. A Teams conversation ID remains accepted."`
	Limit          int    `json:"limit,omitempty" jsonschema:"Maximum number of messages to return; zero returns all."`
}

internal/teamsctl/mcp.go:136

• service.Messages(..., input.Limit) will pass 0 when limit is omitted, which returns the full message history by default. If limit becomes *int, apply a default (e.g. 50) when nil so the default stays bounded.

	messages, err := service.Messages(target.IDs, target.Name, input.Limit)
	return nil, messages, err

internal/teamsctl/mcp.go:201

• Recipient resolution intentionally returns a missingGroupChatError for multi-person reads when no existing group chat is found. There is currently no test asserting that get_messages returns this clear error (and does not fall back to multiple 1:1 conversations). Adding a test for this behavior would align with the documented contract.

	if recipients := splitRecipientNames(target); len(recipients) > 1 {
		conversation, err := s.findGroupConversation(recipients)
		if err != nil {
			return conversationTarget{}, err
		}
		if len(conversation.IDs) == 0 {
			return conversationTarget{}, &missingGroupChatError{Recipients: recipients}
		}

internal/teamsctl/mcp.go:158

• The new missing-group fallback behavior in sendMessage (resolving individuals and sending N separate messages) is not covered by tests. Adding an integration/unit test for the missingGroupChatError path would help prevent regressions in recipient resolution and ensure the fallback reporting fields stay stable.

This issue also appears on line 194 of the same file.

	target, err := service.resolveConversationTarget(firstNonEmpty(input.Recipient, input.ConversationID))
	if err != nil {
		var missingGroup *missingGroupChatError
		if !errors.As(err, &missingGroup) {
			return nil, nil, err
		}
		target, err = service.resolveIndividualTargets(missingGroup.Recipients)
		if err != nil {
			return nil, nil, err
		}
		target.FallbackToOneOnOne = true
	}

docs/superpowers/specs/2026-08-04-mcp-sdk-recipient-resolution-design.md:13

• The design spec says the MCP server runs through mcp.StdioTransport, but the implementation uses mcp.IOTransport in RunMCP. Update the spec to match the actual transport to avoid future drift and confusion.

`teamsctl mcp` will construct an SDK `mcp.Server`, register typed tools, and
run it through `mcp.StdioTransport`. The SDK owns initialization, protocol
negotiation, JSON-RPC framing, input schema generation, and tool dispatch.